Due to the increasing presence of wireless networking hardware, and the increasing throughput of wireless network communication, to number of users relying on wireless network connections continues to grow at a rapid pace. In addition, because of the need to remain connected to corporate intranets, or the Internet, while traveling, users are increasingly relying on foreign hosts to act as gateways to the users' intended networks. However, each of these trends increases the risks that the users' sensitive information can be accessed by rogue third parties. Wireless communications are easily intercepted by anyone with wireless hardware within range of the wireless signals. Additionally, the foreign network host may be unknown to the user and, therefore, cannot be trusted with sensitive information.
In general, network communication relies on various protocols to enable the transport of information between network hardware. One such common protocol is the Point-to-Point Protocol (PPP). PPP encapsulates datagrams from higher level protocols into a packet having a protocol field, an information field, and a padding field that can be optionally used to increase the packet size to that of the maximum receive unit (MRU) for the network. PPP also defines a Link Control Protocol (LCP) for establishing, configuring, and testing the PPP connection. An LCP packet has a protocol field with a value set to the ASCII number “c021” to indicate that it is an LCP packet. The information field contains the necessary information to perform the functions of LCP. Generally, there are three classes of LCP: link configuration packets, which can be used to establish and configure a link, link termination packets, which are used to terminate a link, and link maintenance packets, which can be used to manage and debug a link. LCP's link configuration packets can be used to configure a particular type of authentication mechanism to provide some level of security between the two communicating endpoints.
Authentication can be “one-way”, in which one endpoint authenticates itself to the other end point, or it can be “two-way”, in which both endpoints authenticate themselves to each other. Authentication generally relies on a shared secret that each of the two legitimate endpoints know, but which a rogue third party does not know. An endpoint has authenticated itself when it proves, to the satisfaction of the other endpoint, that it knows the shared secret, and is, therefore, legitimate. Once authentication is complete the two endpoints have proven their identities to one another and can then Implement whatever security has been agreed to so as to protect the transmission of all subsequent communications.
Authentication mechanisms attempt to avoid transmission of the shared secret itself because authentication generally occurs prior to the agreement, by the two endpoints, upon a common encryption protocol with which to protect theft communication. Thus, many authentication mechanisms are said to take place “in the clear” because the information exchanged during the authentication phase is not encrypted prior to its transmission. As a result, authentication mechanisms rely on one-way hashes or similar methods to prove knowledge of the shared secret, without transmitting information from which the shared secret can be reverse engineered. For example, both endpoints can apply the same one-way hash to the shared secret, such as a user-selected password. Each endpoint will derive the same value as a result of the one-way bash; a value from which the password cannot be reverse engineered. When one endpoint transmits the value to the other, the receiving endpoint can compare this received value to the value it calculated to verify that they match. If the two values are the same, the transmitting endpoint has proven its knowledge of the shared secret and is, therefore, authenticated.
PPP provides for a number of authentication mechanisms, including the Challenge Handshake Authentication Protocol (CHAP) and MS-CHAP. In addition, an Extensible Authentication Protocol (EAP) has been developed for providing a mechanism by which the authentication protocol to be used can be negotiated by the two endpoints. EAP can be initially negotiated between the two endpoints using LCP. Once EAP has been negotiated, the two endpoints can use EAP to negotiate a particular authentication protocol, such as CHAP or MS-CHAP. EAP allows two endpoints to agree on an authentication protocol even if intermediate network points do not understand the selected protocol. These intermediate points can merely act as a pass-through of EAP packets and do not impact the selection of an authentication protocol.
However, most authentication protocols, including various versions of the CHAP mechanism, and EAP itself, transmit certain information “in the clear” without the security of a one-way hash or similar mechanism. For example, the user's name or identification is generally transmitted without using a hash or similar mechanism. If the user's name or identity is intercepted, the user's anonymity can be compromised. Additionally, despite the fact that the value derived by applying a one-way hash to the shared secret will not allow a rogue interceptor to reverse engineer the shared secret, the shared secret can be determined through an off-line dictionary attack. Because most users choose an English word or name as their password, a rogue interceptor need only attempt several thousand English words or names as opposed to all of the hundreds of thousands of possible combinations of characters. Using such an off-line dictionary attack, the rogue interceptor uses the same one-way hash as the two endpoints and hashes every word in the dictionary until finding a word whose hashed value is equivalent to the transmitted hashed value that was intercepted. In such a manner a rogue interceptor can obtain a user's password.